[Previous] [Next] [Index] [Thread]

Re: Comments on the new SHTTP draft of July, 1995

I've tried to delete points where we seem to be in agreement....


>> As I think I've expressed to you before, I think that this is
>> a real mistake in HTTP, so I'm not inclined to extend that
>> mistake. 
>
>I'm not particularly fond of case-sensitivity in HTTP in this context either,
>but that isn't the point.  It's hard to define new functionality if we're
>forever dinking with inconsequential basics.
I certainly agree with this sentiment.


[...]
> However, I still think
>the default value should be "binary" and not "8bit".
Ok.


>> >I'm assuming the standard padding mechanism defined in section 6.2 of
>> >PKCS-5 (and also in RFC 1423) is used (being generalized for
>> >algorithms with block sizes larger than 8 bytes.) I think it's obvious
>> >that this is what most people would do in an implementation, but it
>> >probably should be explicit since it isn't defined elsewhere as it is
>> >for the contents.
>> Actually, this doesn't work properly. Consider the case of DES
>> where the keylength is exactly equal to the blocksize.
>
>Then you pad by adding eight bytes of value 08.  It's unfortunate that
>this adds a whole extra block, but there isn't much by way of a good
>alternative, and the use of this padding is pretty darn established.
>(Well, there's the alternative of only allowing stream ciphers as
>symmetric-head-algorithms, but I hardly think we could do that.)

True, this is the canonical padding scheme for CBC, but not necessarily
for ECB mode. If you look at RFC-1423, S 5, you'll see
that the mode of employment for DES-ECB as a DEK encryption
algorithm where the DEK is for DES-CBC (i.e. 64 bits) is
to simply encrypt the DEK as one cipher-block in ECB
mode.

In any case, The only reason to do this kind of padding (as
opposed to say simple padding with zeros) is to unambiguously
distinguish the end of the data, when the end of the data isn't
otherwise unambiguously determined. I'd rather arrange that
the keylength is unambiguously determined and then pad with
zeros or random data in the cases where it's necessary to
fill out a cipher-block.


>Even without RC4 support, using the dek as a shared secret for a keyed 
>hash in the MAC-Info: header requires knowing where the key stops and the pad
>begins, and there's no algorithm identifier to provide this information.
The only time you'd use DEK would be if you were encrypting the message,
in which case you would know the algorithm you were using and therefore
the keylength. Except, possibly, for the case of RC4, which I agree,
could be a problem. I'll look into it.


>> What do you think contradicts? The language about 'retained
>> connections'?
>
>Yes.  Being good for perhaps only one transaction, and being good for lots
>of transactions over the duration of a connection, are different things.
>I'd expect we'll want a different label for "session" keys with longer
>lifetimes than a single use.

Of course, since we don't have retained connections, this is a bit
of a moot point, but a fair one nevertheless. 


>I'm also still vague on the purpose of "this".
I intended 'this' to be used for Key-Assigns which were
supposed to refer to keys used in the message in which they appear.

So, for instance, you could use the Kerberos method to assign
a key (in the S-HTTP headers) which you then used to encrypt
the message that followed. 

-Ekr
Follow-Ups: